With the development and advancement of communication technologies, network service applications have become a part of our daily lives. Peer-to-peer (hereinafter abbreviated as P2P) networking, for example, is a widely used technique nowadays whereby a user's network device (e.g., a desktop computer) can make direct connection with another user's network device through a P2P network to enable voice chat, video transmission, data sharing and exchange (e.g., pictures, music, and video recordings), distributed computation, or work in cooperation, to name only a few P2P applications.
In use, however, P2P networking is faced with problems associated with Network Address Translators (NATs). NATs are typically deployed at the border between a private network and a public network to carry out network address translation, which is an Internet standard defined in RFC 1631 and which mainly involves performing Internet Protocol (IP) address conversion on packets sent by network devices in a private network, so as for multiple network devices in a private network to make Internet connections using a common public IP address. More specifically, when an outgoing data packet of a private network reaches a NAT, the NAT converts the private IP address of the packet into a public IP address before sending the packet out. Likewise, when receiving an external packet, the NAT checks the public IP address of the packet against the information in a mapping table stored in the NAT, converts the public IP address into a private IP address according to the mapping table, and then forwards the packet to the corresponding network device in the private network.
As described above, NATs are configured to shield private networks by rendering the network devices behind a private NAT invisible to public networks. Hence, network devices which are respectively behind different private NATs cannot traverse the NATs to make direct connection with one another by P2P networking. To solve the NAT traversal problem, the User Datagram Protocol (UDP) hole punching technique was proposed, which works in the following manner. A network device behind a NAT begins by connecting with a server in a public network; consequently, the NAT establishes a mapping between the private IP address/port of the network device and a public IP address/port of the NAT and opens a port on the public interface of the NAT. Once the port is opened, network devices in the public network can transmit data through the port to the aforesaid network device behind the NAT. The effectiveness of UDP hole punching, however, is limited to a large extent by the mapping behavior and filtering behavior of the NAT. Besides, the port opened on the public interface of the NAT must be made known by the server in the public network. In order for UDP hole punching to work effectively, Session Traversal Utilities for Network Address Translation (or STUN for short) are called for.
STUN is a network protocol that enables a network device behind a NAT to find network information related to making connections, thus allowing two network devices respectively behind different NATs to connect to each other. The principle of STUN is briefly stated as follows. To start with, a network device behind a NAT sends a plurality of binding requests to a STUN server. Upon receiving each binding request, the STUN server sends out a binding response in reply, wherein the binding response includes the IP address and port number of the NAT as discovered by the STUN server. After receiving the binding responses, the network device behind the NAT can assess the mapping behavior and filtering behavior of the NAT and is notified of the port opened on the public interface of the NAT.
The STUN technique is described in more detail below. Generally, a STUN server with two public IP addresses is required for STUN detection, and a network device behind a NAT must transmit and receive plural UDP packets to and from the STUN server, wherein the UDP packets contain information that the network device needs to know, such as the IP address used by, and the port opened on, the public interface of the NAT. Using the information in the UDP packets, the network device can determine the type of the NAT behind which the network device is located. The foregoing process is now elaborated by means of an example based on the following assumptions: a network device Host A is located behind a NAT X, has the IP address IPa, and opens the port Pa1; and a STUN server is located in a public network and has two public IP addresses IPs1 and IPs2, wherein IPs1 opens two ports Ps11 and Ps12, and IPs2 opens one port Ps21. The network device Host A can obtain the mapped-address, and assess the mapping behavior and filtering behavior, of the NAT X by the following steps, in which the steps performed by the network device Host A to assess the mapping behavior of the NAT X are as follows:
(101) The network device Host A sends a first binding request through the port Pa1 with the IP address IPa to the public IP address IPs1 of the port Ps11 of the STUN server. After receiving the first binding request, the STUN server sends a first binding response through the port Ps11 with the public IP address IPs1 to the network device Host A in reply. The first binding response indicates the IP address of, and the port opened on, the public interface of the NAT X.
(102) Then, the network device Host A sends a second binding request through the port Pa1 with the IP address IPa to the public IP address IPs1 of the port Ps12 of the STUN server. After receiving the second binding request, the STUN server sends a second binding response through the port Ps12 with the public IP address IPs1 to the network device Host A in reply. The second binding response also indicates the IP address of, and the port opened on, the public interface of the NAT X.
(103) Next, the network device Host A sends a third binding request through the port Pa1 with the IP address IPa to the public IP address IPs2 of the port Ps21 of the STUN server. After receiving the third binding request, the STUN server sends a third binding response through the port Ps21 with the public IP address IPs2 to the network device Host A in reply. The third binding response, too, indicates the IP address of, and the port opened on, the public interface of the NAT X.
(104) Based on the binding responses received, the network device Host A determines whether the mapping behavior of the NAT X is independent, address-dependent, or address and port-dependent. More specifically, the mapping behavior of the NAT X is independent if the ports indicated in all the binding responses are the same, address-dependent if only the ports indicated in the first and the second binding responses are the same, or address and port-dependent if the ports indicated in the binding responses are all different.
The steps performed by the network device Host A to assess the filtering behavior of the NAT X are as follows:
(111) The network device Host A sends a first binding request through the port Pa1 with the IP address IPa to the public IP address IPs1 of the port Ps11 of the STUN server. After receiving the first binding request, the STUN server sends a first binding response through the port Ps11 with the public IP address IPs1 to the network device Host A in reply. The first binding response indicates the IP address of, and the port opened on, the public interface of the NAT X.
(112) Then, the network device Host A sends a second binding request through the port Pa1 with the IP address IPa to the public IP address IPs1 of the port Ps11 of the STUN server, wherein the second binding request has its CHANGE-REQUEST attribute set as “port”. After receiving the second binding request, the STUN server sends a second binding response through the port Ps12 with the public IP address IPs1 to the network device Host A in reply. The second binding response also indicates the IP address of, and the port opened on, the public interface of the NAT X.
(113) Next, the network device Host A sends a third binding request through the port Pa1 with the IP address IPa to the public IP address IPs1 of the port Ps11 of the STUN server, wherein the third binding request has its CHANGE-REQUEST attribute set as “IP address”. After receiving the third binding request, the STUN server sends a third binding response through the port Ps21 with the public IP address IPs2 to the network device Host A in reply. The third binding response indicates the IP address of, and the port opened on, the public interface of the NAT X, too.
(114) Based on the binding responses received, the network device Host A determines whether the filtering behavior of the NAT X is independent, address-dependent, or address and port-dependent. More specifically, the filtering behavior of the NAT X is independent if the network device Host A receives all the binding responses, address-dependent if the network device Host A receives only the first and the second binding responses, or address and port-dependent if the network device Host A receives only the first binding response.
It can be known from the above that a STUN server must interact with a network device behind a NAT many times in order for the network device to know the mapped address, mapping behavior, and filtering behavior of the NAT. Now that the prevalence of NATs must increase with the exhaustion of IPv4 addresses, more and more network devices will be located behind NATs and require the assistance of STUN servers in obtaining the mapped addresses, and assessing the mapping behaviors and filtering behaviors, of their respective NATs. Such a rising demand of assistance, however, will add greatly to the workload of STUN servers. Today, network service providers are endeavoring to find an effective solution to this problem, with a view to relieving the burden on STUN servers while allowing network devices to rapidly obtain information of their respective private NATs.